VXML browsers provide an execution environment for VXML scripts, which describe the user-interfaces of applications driven by, for example, touch-tone digit recognition or speech recognition. For Example, VXML browsers and associated scripts may provide the interface for interactive voice response (“IVR”) systems, which typically use touch-tone digit recognition. VXML browsers and scripts also may be used to provide application interfaces for push-to-talk systems, such as, for example, two-way radios, which lack numeric keypads and, therefore, must use speech recognition.
Several commercially available products today have some capability to communicate with VXML browsers. For example, interactive source level debuggers exist. Debuggers provide a mechanism to view and control the execution of the source code, and inspect the values of code variables. Multi-modal products also exist. For example, the VOX Gateway™, from Motorola, Inc., permits control over a VXML browser, where VXML fragments are embedded in a J2ME (“J+V”) application running on a Motorola cell phone; the VXML fragments are sent to a VXML browser for execution, so that the user's voice input can be recognized. Similarly, IBM has demonstrated an “X+V” system that executes VXML scripts embedded in a hypertext markup language (“XHTML”) environment. This configuration runs in the Opera™ web browser. Other products that function with the VXML browser are voice-application test harnesses. These test harnesses place calls to IVR systems, which support VXML, to perform rudimentary verification of system availability, responsiveness, and correctness. However, the test harnesses fail to inspect the internal state of the system to determine whether the browser's internal states are correct.
Against this background, it would be desirous to develop a communication or control channel that allows for the above and other functionality to be implemented in a VXML browser.